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SOME  PRACTICAL  COMMENTS  ON  THE 
DETEIDPMENT  OF  ACTIVITY- EVENT  FLOW  NETWORKS 


I ,  IntroduetloR 

Th«  aost  difficult  step  In  the  impleoeiitation  of  a  PERT-PEP  type  of 
nanagement  system  is  the  development  of  an  activity-event  flow  network  which 
represents  the  job  to  be  accomplished.  An  activity-event  flow  network  is  a 
plan  showing  the  time  sequenced  steps  needed  to  reach  a  stated  objective, 
such  as  the  R&D,  testing,  tooling,  establishment  of  a  logistics  system,  etc., 
needed  to  make  a  weapon  system  operational.  It  is  a  graphical  presentation 
of  the  things  to  be  done  in  the  order  they  must  occur,  plus  an  identifica¬ 
tion  of  significant  beginning  points  and  accomplishMnts.  This  paper  is  an 
attempt  to  describe  networks  and  their  building  blocks,  and  to  set  forth 
soma  methods  for  their  development.  It  is  not  meant  to  establish  rigid  pro¬ 
cedures,  but  only  to  suggest  methods  and  alternatives  which,  in  the  experience 
of  the  author  and  others,  have  proved  useful. 

A  network  must  be  realistic,  comprehensive,  and  Include  a  proper  level 
of  detail.  Its  development  will  usually  be  participated  in  by  both  managers 
or  technicians  responsible  for  the  tasks  being  networked,  and  by  |i^n  familiar 
with  networking  and  with  the  operation  of  the  PERT-PEP  system.  Often,  the 
network  will  cover  areas  in  which  the  relationships  and  interactions  between 
activities  have  not  been  previously  considered  in  anything  approaching  a 
comprehensive  manner,  so  that  in  effect  the  process  of  networking  is  the 
process  of  setting  down  for  the  first  time  a  complete  program  plan.  In  other 
cases,  come  form  of  milestone  or  Gantt  chart  plan  will  precede  the  network, 
but  it  will  not  have  the  activity  and/or  the  interaction  orientation  which  is 
characteristic  of  a  network.  The  plan  often  turns  out  to  be  either  incomplete 
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or  at  least  not  specific  enough  to  satisfy  rigorous  networking  requirements. 
Thus,  Lt  is  necessary  to  go  through  what  usually  turns  out  to  be  a  long  and 
difficult  session  of  defining  events  and  activities  and  their  relationships 
over  time.  The  results,  however,  will  be  a  plan  of  unusual  clarity,  complete¬ 
ness.  and  usefulness  in  the  areas  of  programming,  status  monitoring,  and 
for  ecasting . 

Flow  networks  are  activity  and  activity- interaction  oriented.  This 
is  a  major  improvement  over  the  milestone  system  which  concentrates  on  the 
points  in  time  when  various  items  are  complete  or  available  rather  than  the 
human  and  machine  effort  which  makes  up  the  activities  which  must  be  completed 
to  reach  the  milestones.  It  is  these  activities  -  their  objectives,  manpower 
assigned,  facilities,  methods,  etc.  -  which  are  truly  under  the  control  of 
management.  It  is  also  an  improvement  over  the  Gantt  chart,  which  shows 
activities  but  either  does  not  indicate  their  relationships  (what  must  be 
completed  before  others  can  begin)  or,  at  best,  indicates  most  of  the  inter¬ 
actions  simply  as  occurring  at  specified  times  after  the  beginning  or  before 
the  completion  of  the  activities  concerned.  These  charts  usually  fail  to 
identify  specifically  progress  which  must  be  made  before  the  tie-ins  between 
activities  are  either  available  or  required.  It  is  these  concepts  of  ex¬ 
plicitly  specifying  the  activities  and  their  points  of  interaction  which  is 
the  backbone  of  networking  -  both  in  use  and  in  construction  -  and  it  is 
quite  important  that  they  be  kept  constantly  in  mind. 
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II,  Definitions  and  Suggestions  for  Creating  the  Network.  Components 


A.  The  Events 

Events  ate  points  in  time  which  indicate  the  beginning  of  or  the  completion 
of  one  or  more  activities.  They  are  useful  as  status  monitoring  points,  and 
as  at  least  partial  descriptions  of  the  activities  which  are  their  basis. 

Often  they  may  be  points  of  decision,  where  alternatives  are  eliminated  or 
chosen  -  or  where  the  program  might  be  discontinued.  In  many  cases  they  may 
be  simply  "Begin  Activity  X'"  or  "Complete  Activity  X.’*  In  other  cases,  they 
may  represent  the  accomplishment  or  beginning  of  a  significant  phase  of  the 
total  job,  or  the  transfer  of  responsibility  from  one  organization  to  another, 
and  thus  may  be  the  completion  or  initiation  of  several  activities.  It  is  for 
this  reason  that  the  events  by  themselves  cannot  always  specify  all  of  the 
activities  which  are  connected  to  them. 

Events  do  not  take  time  in  themselves  to  complete  -  they  either  are,  or 
aren't.  They  exist,  or  don't.  One  moment  they  have  not  been  reached,  the 
next  they  have  been  reached.  As  such,  not  only  is  a  description  of  the  event 
needed,  but  evidence  of  its  existence  must  be  identifiable.  Fbr  Instance,  the 
event  might  be  systems  budget  estimates  completed",  and  the  evidence  would  be 
the  release  of  the  document  by  the  responsible  office.  In  order  to  be  assured 
that  the  event  is  truly  significant,  it  is  wise  to  specify  the  evidence  and 
the  reporting  office  when  initially  describing  the  event. 

B.  The  Activities 

Activities  are  things  being  done,  characterized  by  people  using  facilities 
over  some  period  of  time  to  accomplish  a  stated  objective.  Activities  imply 
doing  -  preparing,  researching  building  negotiating,  deciding, ' testing,  etc. 
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Activities  are  the  of  a  flow  network,  and  it  is  this  flow  of  human  effort, 

materials,  use  of  facilities,  investment,  expenses,  and  progress  towards  an  ob¬ 
jective,  which  can  be  controlled  by  the  manager. 

More  basically,  anything  which  takes  time  is  an  activity.  Thus,  the  time 
required  by  transmittal  of  information  or  delays  made  necessary  by  regulations 
or  contract  provisions  are  properly  shown  as  activities.  Administrative  deci¬ 
sions  to  begin  an  activity  some  time  after  it  could  have  begun,  approvals  in¬ 
volving  decision  time,  fabrication  of  a  vehicle,  development  of  an  electronic 
component  ~  all  these  are  time  consuming  and  are  thus  activities  in  the  network. 

The  rigorous  nature  of  the  flow  networks  requires  that  the  activities  be 
independent.  That  is,  activities  occurring  simultaneously  must  be  performed  by 
different  people  or  organizations  and  require  no  inputs  from  each  other.  They 
must  be  able  to  take  place  independently  of  each  other,  and  not  require  any 
inputs  other  than  those  shown  by  the  network  as  feeding  into  the  initiating 
event.  Further,  the  activities  in  series  with  each  other  must  also  be  indepen¬ 
dent  -  that  is.  the  time  which  one  takes  should  not  effect  the  time  which  any 
of  the  following  ones  take  -  for  the  statistical  mathematics  used  in  combining 
times  becomes  invalid  if  this  condition  does  not  exist. 

It  is  good  practice  to  define  explicitly  each  activity,  as  well  as  each 
event,  as  the  network  is  developed,  and  to  list  the  responsible  office  and  the 
evidence  of  completion.  Often  they  will  be  the  same  as  for  the  event  which 
signals  the  end  of  the  activity,  but  when  two  or  more  activities  lead  into  one 
event,  the  event  cannot  conveniently  describe  both.  Some  organizations  using 
flow  network  management  systems  have  not  gone  to  this  additional  "bother'  , 
relying  on  the  event  to  specify  the  preceding  or  succeeding  activities.  Con¬ 
sequently.  they  have  to  some  extent  lost  the  activity  orientation  which  is  so 
basic  to  the  system,  and  have  in  addition  created  networks  which  are  not  as 
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easily  andcrstood.  There  is  danger  rn  so  doing  that  the  network  will  be  less 
accurate  and  realistic  than  it  would  be  if  ail  activities  are  identified,  for 
the  responsible  people  creating  it  will  not  have  explicitly  before  them  as 
clear  and  concise  a  picture  of  the  plan  they  are  laying  out.  For  the  same 
reason  the  next  higher  level  of  management  will  find  it  less  useful  than  it 
could  be  to  them  for  monitoring  planning,  etc, 

C ,  Restraints  or  Zero- 1 ime  Act iv Area 

The  concept  of  a  zero  time  activity  ,  r  a  ‘restraint’  is  also  useful.  This 
IS  simply  a  specialized  type  of  activity  most  easily  identified  by  using  a 
dotted  line  on  the  network  layout  which  constrains  the  beginning  of  a  following 
activity,  or  the  completion  of  the  event  to  which  it  leads  by  requiring  that 
the  event  from  which  it  proceeds  be  completed  first.  However  there  is  no 
specific  activity  required  between  two  events  connected  by  a  restraint.  It  is 
often  used  to  tie  the  completion  of  several  activities  to  the  beginning  of  a 
single  activity,  or  vice-versa. 

This  is  shown  in  the  illustration  below,  where  events  are  shown  as  circles, 
activities  as  solid  arrows  and  restraints  as  dotted  arrows.  Events  1  to  3 
might  be  the  completion  of  a  test  airframe  engine,  and  guidance  system:  event 
4  would  be  the  beginning  of  the  W/S  assembly. 
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The  restraint  may  also  be  used  in  exceptional  cases  when  it  is  desired  to 
indicate,  by  separate  events,  the  ending  of  one  activity  and  the  beginning  of 
the  following  one.  This  may  be  desirable  in  cases  where  the  completion  of  one 
activity  is  of  major  significance,  and  where  it  is  necessary  to  be  quite  sure 
that  the  following  activity  begins  immediately  as  planned. 


— >(T) — ^ ^ 

Although  activity  2-4  (B)  can  begin  upon  the  completion  of  activity  1-2  (Ajj 
there  is  no  guarantee  that  it  will  do  so.  The  addition  of  restraint  2-3  and 
event  3  insures  that  the  beginning  of  activity  3-4  (B)  is  recognized  as  im¬ 
portant  and  is  reported  upon. 

D.  Other  Definitions 

A  series  of  activities,  which  could  be  considered  a  small  network  in  itself, 
L3  often  referred  to  as  a  "task.-  A  task  can  often  be  represented  as  one  in¬ 
dependent  activity  when  summarized. 

A  milestone  and  an  event  are  almost  synonymous,  but  a  milestone  usually 
refers  to  a  very  important  event.  All  events  in  a  top  level  summary  network 
might  be  milestones. 

E.  Less  Rigorous  Activity  Definitions 

It  is  sometimes  difficult  to  identify  the  beginning  and  ending  points  of 
activLties  using  the  strict  flow  network  criterion  which  states  that  an  event 
is  not  completed  until  all  activities  leading  to  it  are  completed  and  that  no 
activity  leading  from  an  event  begins  until  the  event  is  completed.  Another 
difficulty  lies  in  the  assumption  of  independence,  for  often  it  is  not  useful 
to  go  to  a  level  of  detail  which  breaks  out  every  point  of  interaction  between 


6 


V 


two  or  more  activities. 

A  coRvenient  and  sometimes  necessary^  approximation  in  cases  o£  this  nature 
involves  defining  events  and  activities  as  ’'essentially  begun"  or  "essentially 
completed."  By  this  is  meant  that  the  greater  part  of  the  effort  then  begins 
(or  ends),  even  though  some  work  had  started  previously.  It  might  be  the  point 
at  which  most  of  the  people  who  are  assigned  to  the  activity  begin  their  effort, 
or  a  point  in  time  when  enough  of  the  work  is  accomplished  so  that  following 
activities  can  begin.  Although  the  network  retains  its  strict  activity-event 
interrelationships  and  restraints,  the  human  input  is  allowed  to  retreat  somewhat 
from  the  rigorous  criterion,  and  to  set  down  expected  real  world  situations  that 
simply  cannot  be  stated  except  by  approximations  of  soa^  type.  This  method 
of  networking  areas  where  the  beginning  and  ending  points  of  activities  are  not 
entirely  clear  nor  readily  described  should  not  be  used  as  a  generalized  pro¬ 
cedure,  but  should  be  reserved  for  those  activities  which  have  previously  eluded 
the  more  rigorous  approach.  Extension  beyond  the  minimum  possible  use  would 
result  in  defeat  of  the  purpose  of  networking  -  complete  and  exact  plannings 

The  problem  of  independence  arises  when  two  (or  more)  tasks  have  many 
points  of  interaction,  often  of  an  information  exchange  nature.  If  networked 
rigorously,  these  would  be  divided  into  a  very  large  number  of  short  and  overly 
detailed  activities.  One  possibility  for  avoiding  this  is  to  combine  the  two 
tasks  into  one  activity  in  the  network,  looking  at  it  as  a  joint  effort  of  the  two 
groups  or  individuals  involved.  However,  if  the  distinction  between  the  two  is 
desirable,  and  it  is  felt  that  the  interactions  will  not  be  of  a  delaying  nature, 
the  two  can  be  shown  separately  as  two  approximately  independent  activities. 

These  situations  should  be  noted  for  special  surveillance  so  that  delays  occurring 
in  the  middle  of  one  activity,  due  to  delays  in  the  other,  can  be  identified  rapidly. 
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The  dotted  lines  indicate  information  exchange.  These  could  be  elimin¬ 
ated,  leaving  the  two  'approximately  independent"  activities  of  'design  airframe" 
and  "design  propulsron  system. 

F,.  Forms  of  Expressing  Event  and  Activity  Names 

In  order  to  avoid  the  confusion  found  in  many  milestone  lists,  and  to 
generally  improve  the  clarity  of  presentation,  considerable  attention  should 
be  given  to  the  names  of  events  and  activities  An  activity  implies  doing 
or  action,  and  thus  should  be  expressed  as  a  verb  form  (develop,  testing, 
complete;  which  will  not  be  confused  with  the  beginning  or  completion  point 
of  the  activity.  Events  should  be  noun  forms  to  express  a  state  of  being 
(developed-  tested,  completed,  begun):  words  which  imply  the  passage  of  time 
•I  should  be  avoided.  Each  identifier  should  be  concise,  so  that  various 
personnel  with  different  backgrounds  and  points  of  view  will  interpret  it  in 
the  same  manner.  Strict  adherence  to  these  practices  will  be  of  help  to 
operating  personnel  in  the  construction  of  networks  for  it  will  tend  to  keep 
them  in  a  state  of  mind  conducive  to  exactness  and  completeness,  It  will 
make  the  job  of  evaluation  less  difficult  for  everyone  concerned,  and  will 
ease  the  job  of  extracting  unambiguous  major  events  ("milestones  ')  for 
summary  networks’  or  management  reports. 
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G.  A  Few  Suggestions  Concerning  the  Graphics 

The  usual  procedure  for  representing  events  is  to  use  circles  or  boaces, 
although  some  organizations  have  resorted  to  a  number  ef  various  shaped  en¬ 
closures  to  represent  various  types  of  events  (colors  may  be  used,  but  their 

reproduction  is  difficult).  Each  subsystem  might  use  a  different  shape,  or 

r  e 

each  A.F.  management  function  might  be  shown  differently  (research,  logistics, 
GSE,  testing,  etc.).  Another  procedure  involves  laying  out  regularly  spaced 
boxes  to  cover  an  entire  page,  reproducing  these  worksheets,  and  filling  in 
and  connecting  those  which  are  convenient. 

Activities  are  shewn  as  solid  lines,  or  sometimes  as  double  lines  if 
they  are  on  or  near  the  critical  path.  Dotted  lines  distinguish  the  re¬ 
straint.  It  la  preferable  to  lay  out  the  network  In  such  a  way  that  all  arrows 
flow  from  left  to  right,  both  for  clarity  to  the  users  and  to  reduce  reproduc¬ 
tion  errors. 

Large  pieces  of  paper  are  needed  for  networking,  for  each  event  and  each 
activity  must  be  defined  using  several  words,  and  responsible  agencies  and 
tines  estimates  must  be  included.  As  an  example,  one  network  recently  construc¬ 
ted  used  squares  ll’-  on  a  side  for  events,  left  a  minimum  of  2‘-  between  events 
for  activity  lines,  and  placed  a  mnTimum  of  fifty  events  on  a  piece  of  paper, 

24  by  36  inches. 

Time  scales  should  be  avoided  until  networks  are  approved  and  ready  for 
presentation.  A  very  clear  presentation  then  results  from  laying  out  the  events 
on  a  time  scale  according  to  their  calculated  Expected  Time,  and  differentiating 
slack  time  from  activity  time  by  using  different  types  of  lines.  However,  a 
complete  new  drawing  is  needed  each  time  a  change  occurs  in  an  Expected  Time, 
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Graphical  Presentation  to  Management 
(not  a  network  worl;  sheet) 


critical  path 
activity 

slack 


The  horizontal  length  of  each 
line  is  time  scaled.  The  events 
appear  above  their  calculated 
Expected  Time. 


Slack  may  be  associated  with  a  slack  path  of  everal  activities  (such  as 
I,  2,  4,  6,  7;  or  7,  9,  11;  or  5,  5,  8;  or  7,  8,  10,  11)  or  with  a  slack  ‘path' 
of  one  activity  (such  as  7,  10;  or  9,  11).  In  any  case,  the  slack  is  part  of 
the  entire  path  and  not  (necessarily)  part  of  one  activity. 


10 


Ill ,  The  Network  as  a  System 


s. 


A.  Types  of  Networks 

Two  t3rpes  of  networks  which  have  quite  different  nanagement  chatACterls- 
tics  have  evolved  frcm  PERT-PEP  sy^stea  developments.  One  is  made  up  of 
'’hardware  oriented”  activities  such  as  research  and  development,  tooling,  pro¬ 
duction,  testing,  etc.  -  anything  which  relates  directly  to  physical  progress 
on  the.^jsh  to  he  done.  The  other  is  made  up  of  “management  activities**  such  as 
planning,  funding,  approving,  negotiating,  inspection,  etc.  all  of  those 
activities  which  management  nnist  accomplish  in  order  to  keep  the  “hardware 
activities”  continuing  on  schedule. 

•  It  may  seem  that  these  two  “types"  of  networks  are  not  separate  at  all, 
but  are  really  only  parts  of  one  network  describing  the  total  job  to  be  done. 
This  is  of  course  true.  All  of  the  activities  in  each  network  have  to  be 
accoapilshed,  and  any  activity  in  either  one  could  be  the  one  which  delays  the 
final  objective.  Approvals  and  decisions  and  various  sorts  of  documentation 
are  as  important  to  the  completion  of  the  overall  job  as  are  research  and  fab¬ 
rication  and  delivery  of  GSE. 

Rowever ,  most  networks  presently  in  use  concentrate  almost  entirely  on 
the  "hardware  activities'  (develop,  test,  tool,  prodncc)  to  the  exclusion  of 
the  “management  activities"  (fund,  decide,  approve,  negotiate).  A  truly  use¬ 
ful  management  network  must  Include  not  only  "management  activities  \  but  also 
portray  in  some  way  the  hardware  (mostly  contractor)  activities;  as  such  it  can 
be  made  up  In-house  for  Air  Force  management  use.  Of  course,  the  contractors 
may  have  more  detailed  networks  of  the  hardware  tasks  available  for  their  own 
use  and  as  a  backup  for  the  A.F.  plan,  although  only  first  level  summaries  of 
these  may  be  kept  on  file  at  the  Air  Force  management  office.  The  realization 
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that  both  types  of  activities  must  be  included  is  quite  important,  though, 
especially  since  experience  to  date  indicates  that  the  initial  networks  for  any 
system  will  usually  be  a  more  or  less  summary  picture  of  the  hardware  job.  Be¬ 
fore  full  potential  of  the  system  can  be  realized  by  Air  Force  management,  the 
management  picture  must  be  developed.  (See  "Weapon  System  Development  Network,' 
#1  &  #2,  prepared  by  the  Operations  Analysis  Office  of  Hq  AMC,  2-61), 

B.  Detail  and  Sammary  Networks 

The  detail  needed  for  a  network  depends  upon  the  level  of  management 
which  will  make  active  ush  of  it.  Top  management  will  want  and  need  only  a 
gross  summary,  while  those  in  charge  of  the  actual  day  to  day  tasks  can  use 
a  network  showing  every  significant  step  involved.  In  any  case,  each  network 
should  be  complete,  in  that  it  covers  the  entire  project  without  omission  - 
to  summarize  does  not  mean  to  omit I 

In  a  summary  network,  each  activity  represents  what  may  be  several  or  even 
a  fdiole  network  of  more  detailed  activities.  For  instance,  an  Air  Force  high 
level  management  network  may  show  an  activity  beginning  with  an  R&D  contract 
being  signed  and  ending  with  a  mock-up  inspection.  The  SPO  would  want  more 
detail,  and  the  contractor  would  need  a  rather  large  network  for  this  task. 
However,  each  level  of  network  is  comprehensive,  as  shown  in  the  following 
figure  which  illustrates  complete  coverage  of  the  detailed  tasks  by  various 
summary  l^els  of  networks?' 

Hq,  USAF 

Hq.  AFSC 


Contractor 


The  definition  of  "significant  activity"  for  any  level  of  interest  includes 
factors  such  as  expected  difficulty  of  the  task,  length  of  time  it  will  take, 
the  magnitude  of  accomplishment  its  completion  implies,  how  many  other  activi- 
ties  interact  with  its  beginning  or  completion,  etc.  This  will  vary  from 
activity  to  activity  and  from  network  to  network,  but  one  cdomon  factor  is  the 
need  to  consider  the  network  as  a  monitoring  as  well  as  a  planning  tool. 
Management  may  decide  that  it  is  necessary  to  check  on  the  progress  of  activi¬ 
ties  within  a  given  task  at  least  every  "X*"  weeks,  so  that  frequency  of  re¬ 
porting  may  partially  govern  activity  lengths.  In  this  case,  the  "events  per 
reporting  period"’  tinea  the  length  of  the  entire  job  (in  reporting  periods  - 
possibly  two  week  units)  iwuld  provide  an  estinete  of  the  network  size  needed. 
However,  great  care  must  be  taken  not  to  create  artificial,  unrepor table,  or 
insignificant  events  in  an  attempt  to  meet  frequency  of  reporting  criteria. 
Activities  can,  if  necessary,  have  their  remaining  time  re-estimated  every 
"X”  weeks  without  a  significant  event  having  occurred. 

As  more  and  more  detail  is  Included  in  a  network,  it  becomes  easier  and 
easier  to  show  a  true  picture,  for  interactions  are  all  included  explicitly. 
Summarizing  a  network  may  becostoft  quite  difficult  when  large  segments  of  it, 
which  ate  logically  reducible  to  one  activity  each,  have  interactions  from 
internal  points.  In  this  case,  either  more  than  one  activity  stay  be  used,  or 
'weak'  interactions  may  be  neglected  as  discussed  earlier  in  this  paper  (page  7), 
Another  possibility  Is  to  summarize  one  of  the  networks  (if  one  has  no  internal 
interaction  points)  as  one  activity  in  the  other  network.  The  following  figure 
illustrates  this; 
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C.  starting  to  Construct  the  Network 

There  are  several  ways  to  attack  the  construction  of  the  initial  nefwtirk 
for  a  program.  In  some  cases  there  has  been  some  previous  planning  so  that 
a  list  of  milestones  or  possibly  a  typical  summary  network  may  be  available. 

In  other  cases,  the  network  may  be  constructed  using  nothing  more  than  the 
knowledge  of  a  group  of  people  who  are  familiar  with  the  objectives  or  re- 
quiremfents  of  the  project,  and  who  have  had  experience  in  the  functional  areas 
involved. 

If  the  latter  situation  exists,  where  there  is  little  or  no  prior  compre¬ 
hensive  program  planning,  one  may  start  at  the  beginning  event  (program  start) 
or  at  the  ending  event  (program  completed).  Of  course  the  beginning  and 
ending  points  must  first  be  well  defined,  so  that  all  of  the  networking  parti¬ 
cipants  have  a  common  understanding  concerning  the  current  status  and  the  ob¬ 
jective  to  be  reached.  In  any  case,  people  must  be  present  who  have  (among 
them)  a  total  picture  at  a  summary  or  overall  planning  level  of  the  entire 
project,  for  this  group  approach  is  likely  to  be  more  economical  of  time  and 
effort  than  would  be  an  approach  involving  separate  networking  sessions  with 
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many  individuals.  Later,  individual  areas  (one  or  more  activities)  may  be 
selected  for  more  detailed  treatment  and  specialists  in  the  area  will  be 
consulted.  This  "top  level  down"  approach  seems  to  be  the  most  desirable, 
as  it  quickly  produces  an  integrated  picture  of  the  entire  project  and  pro¬ 
vides  a  logical  basis  for  deciding  how  much  of  the  program  must  be  detailed 
down  to  what  level.  Starting  at  a  detailed  level  and  summarising  for 
higher  management  may  result  in  unneeded  work,  too  large  a  network  for  the 
entire  project,  and  uimecessary  delay  in  presenting  an  integrated  plan  to 
management . 

If  one  starts  at  the  beginning,  the  logical  question  "what  can  come 
next"  is  asked  as  each  event  is  completed.  As  an  activity  and  its  concluding 
event  is  added,  the  question  "what  else  must  be  done  in  order  to  reach  the 
event"  is  asked.  This  procedure  may  continue  along  the  progress  of  one  given 
functional  area,  reach  the  final  objective,  and  then  start  again  along  another 
more  or  less  independent  functional  area.  Or,  all  areas  may  be  developed 
concurrently.  The  latter  is  more  difficult,  because  the  advantage  of  follow¬ 
ing  one  train  of  thought  is  lost.  However,  the  former  requires  notation  at 
each  event  of  possible  interactions  with  other  functional  areas,  so  that  connect¬ 
ing  activities  or  restraints  may  later  be  added. 

If  one  starts  at  the  final  event,  the  question  is  "what  activity'  or  "what 
other  activities  must  be  completed"  before  this  event  is  completed.  This  avoids 
the  question  of  what  can  occur  now,  and  sticks  to  the  more  objective  question 
of  what  must  have  occurred.  Often  there  are  a  number  of  activities  for  which 
all  the  prerequisites  have  been  completed  and  which  could  begin  at  a  given 
event.  However,  each  manager  has  a  concept  of  "good  management"  which  dictates 
his  mode  of  operation,  and  within  certain  physical  or  logical  Limits  (you  can’t 
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test  a  V/B  befoiethe  test  facility  is  ready),  he  will  sequence  his  actlYlties 
Ir  a  way  which  will  conform  with  his  ideas.  The  ’’must  have  occurred'*  question 
will  result  in  an  initial  n|twork  free  of  these  management  biases,  and  presents 
a  more  objective  picture  which  may  then  be  modified  as  needed.  However,  ex¬ 
perience  has  shown  that  this  method  of  working  from  the  rear  forward  nay  tend 
to  result  in  more  detail  than  desired,  for  the  operating  people  suy  try  to 
include (qea^eepar ate  activity),  literally  every  minute  detail  needed  for  the 
occurrence  of  an  event. 

Another  approach  which  has  been  found  to  be  successful  entails  the  use 
of  a  simplified  Gantt  bar  chart.  Each  major  area  of  activity  (such  as  each 
subsystem,  or  testing,  or  spare  parts  logistics)  is  represented  as  an  appr(»- 
imate  tiiMi  phased  bar  on  a  time  scale  chart.  Leave  the  bars  far  enough  apart 
so  that  boxes  (events)  may  be  added  along  each  one.  Once  the  major  areas  are 
identified  and  represented  on  the  familiar  Gantt  chart,  the  tine  scale  is  re¬ 
moved  and  major  events  are  identified  and  added  along  each  of  the  activity  bars. 
Interactions  (usually  restraints)  between  them  may  be  easily  added  at  the  same 

time  the  events  are  identified.  Some  portions  of  the  bar  will  be  enlarged  into 
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several  activities  or  even  a  small  sub-network  on  the  first  time  around,  but 
in  general  it  is  easier  to  put  the  entire  chart  into  network  form  at  a  gross 
summary  level  before  attempting  very  stneh  detailing. 

Another  approach  may  be  taken  to  the  development  of  a  project  network  if 
a  milestone  list  has  been  previously  prepared.  In  this  case  it  may  still  prove 
helpful  to  start  by  assembling  a  group  whose  knowledge  encompasses  the  entire 
project;  but  the  prior  preparation  of  a  network  by  the  PEP  staff,  followed  by 
networking  sessions  with  eitlbir  individuals  or  groups,  has  been  found  to  be  a 
reasonable  appro^h.  ,  In  either  case,  to  attempt  to  go  dix'uctly  from  the  list 
to  a  flow  network  may  be  quite  difficult  because, of  the  lack  of  an  activity 
orientation  in  the  list,  but  an  intermediate  step  can  smooth  the  way. 


A  ''dependency  network  j  showing  the  relationships  of  the  events,  may  be 
constructed  by  laying  out  the  milestones  with  connecting  lines  showing  only 
what  milestones  must  be  reached  before  others  can  be  reached.  All  of  these 
lines,  none  of  which  are  at  this  step  Identified  as  activities,  may  not 
necessarily  turn  out  to  be  major  activities  ~  some  will  be  restraints  and 
some  will  be  minor  activities  needed  to  accomplish  an  event  for  which  the 
major  activity  was  not  shown  on  the  dependency  network  (minor  or  major  in  the 
sense  that  the  time  and  effort  spent  on  them  is  small  or  large).  The  figure 


If  dates  (scheduled  or  otherwise)  have  been  assigned  to  the  milestones,  laying 
them  out  along  a  time  axis  will  facilitate  creation  of  the  dependency  network. 
This  axis  should  be  removed  before  identifying  and  adding  activities,  in  order 
to  prevent  identification  of  them  with  previously  set  milestones  and  backoff 
times . 

The  next  step  is  to  list  the  activities  (along  with  the  organi2ations 
which  accomplish  each  one)  which  are  required  to  achieve  each  of  the  events. 
These  activities  may  then  be  located  on  the  chart  as  an  existing  line,  or 
added  as  a  line  and  arrow  leading  to  the  event.  A  logical  beginning  event 
must  also  be  identified,  although  this  may  be  a  management  choice  between 
several  equally  possible  alternative  events  which  might  trigger  off  the  acti¬ 
vity. 
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The  varict&s  netKods  of  laying  out  the  nettroifit  -  starting  at  the  first 
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((MTunt  or  the  ending  event,  using  a  simple  Gantt  chart,  laying  out  a  depend 
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dency  network  fron  a  milestone  list  ~  all  have  one  common  tie.  That  is  the 
desirability  of  starting  with  a  summary  level,  non-detalled  picture  from 
which  further  networks  can  be  developed  if  necessary.  The  approach  taken 
will  depend  upon  how  such  previous  planning  has  been  done  and  upon  the 
preference  of  the  networkers. 

D,  Alternate  paths. 

When  there  are  two  or  more  possible  approaches  to  an  objective,  the 
networks  will  be  faced  with  an  event  which  initiates  one  cw  the  other  of  the 
'  ‘choices  of  activity  paths.  A  flow  network  will  not  recognize  '’or'*,  sO  either 
the  person  responsible  for  the  job  must  choose  the  most  likely  course  of 
action,  or  the  longest  of  the  several  paths  should  be  used.  The. latter  is 
the  conservative  approach,  giving  the  longest  time  span  which  might  be  ex¬ 
pected,  but  the  network  should  be  modified  as  other  paths  become  much  more 
pxobehLe  or  as  the  originally  chosen  one  is  ruled  out. 
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IV,  The  Network  Time  Fstimstes 


It  is  neither  necessary  nor  desirable  to  try  to  arrive  at  time  estimates 
at  the  same  time  as  the  identification  of  the  activities  and  their  relation¬ 
ships  is  being  accomplished.  It  is  best  to  remain  oriented  towards  the  jobs 
to  be  done  rather  than  complicating  the  matter  with  factors  of  manpower, 
facilities,  time,  etc.  In  addition,  the  people  who  lay  out  the  network  may 
not  necessarily  be  the  ones  who  have  the  mos".  specific  knowledge  of  the  magni¬ 
tude  of  each  job,  or  they  may  wish  to  consult  with  others  before  stating  a 
figure.  When  the  network  is  complete,  each  responsible  organization  or  office 
can  then  examine  their  parts  of  the  overall  project  and  arrive  at  time  esti¬ 
mates  , 

The  times  are  not  to  be  confused  with  dates.  Only  flow  times  --  times 
to  accomplish  a  given  activity  once  it  has  been  started  --  are  wanted.  Any 
identification  with  pre-set  schedules  or  backoff  times  from  other  activities 
IS  to  be  avoided,  for  it  nullifies  one  of  the  major  advantages  of  network  pro¬ 
gramming  --  factual  time  flow  estimates  for  specifically  identifiable  indepen¬ 
dent  activities.  Realistic  schedules  are  one  of  the  outputs  (not  inputs)  of 
the  system.  It  has  been  suggested  that  only  small  portions  of  the  network 
be  made  visible  at  a  time,  and  that  the  networker  jump  around  the  network  in 
random  order  after  starting  somewhere  in  the  middle,  when  soliciting  the  time 
estimates. 

The  time  estimate  for  each  activity  consists  of  three  separate  statements 
and  results  in  a  measure  of  the  uncertainty  involved.  It  may  be  difficult  at 
first  to  convince  people  to  make  the  three  estimates,  but  experience  has  indi¬ 
cated  that  they  will  welcome  the  chance  to  express  their  uncertainty  in  quant i 

tative  terms  as  soon  as  they  understand  the  concepts  involved.  Most  activity 
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involving  intellectual  effort  does  not  lend  itself  to  exact  prediction  of  the 
flow  time  (production  line  or  machine  limited  operations  are  of  a  different 
nature) ,  and  it  is  often  the  case  that  exact  schedules  are  met  only  through 
relaxation  of  effort  or,  more  often,  last  minute  speed-ups. 

Time  estimates  for  quantifying  uncertainty,  i.e.,  developing  probability 
estimates,  are  made  assuming  some  given,  pre-planned  outlay  of  effort.  One 
planned  workforce  (which  may  remain  constant  or  may  build  up  and  decline  accord¬ 
ing  to  a  schedule),  number  of  work  hours  per  day  and  days  per  week,  facility 
availability,  budget,  etc.,  is  assumed  when  making  the  three  estimates,  and 
any  change  in  any  of  these  necessitates  three  new  estimates. 

The  first  figure  requested  is  the  most  likely  time.  This  is  the  time 
which  constitutes  the  'best  guess  '  of  the  estimator,  given  the  assumed  condi¬ 
tions  and  average  luck  The  second  figure  is  an  optimistic  time,  given  the 
same  conditions  but  unusually  good  luck  and  rapid  progress.  This  time  is  to 
be  realistically  obtainable,  but  probably  wouldn't  happen  more  often  than  two 
or  three  times  if  the  activity  were  to  be  repeated  a  hundred  times  under  the 
same  conditions  (assuming  each  time  that  it  had  not  been  done  before).  Lastly, 
a  pessimistic  time  is  requested.  Except  for  fires,  floods,  strikes,  and  the 
like,  rather  bad  luck  is  assumed.  The  activity  might  reasonably  take  this 
long  two  or  three  times  if  repeated  a  hundred  times  (each  time  with  no  learning, 
or  experience  factorK  The  three  estimates  are  placed  in  parenthesis  along  the 
activity  line  and  next  to  the  description  (0,  ML,  P). 

The  three  estimates  are  used  to  arrive  at  quantitative  measures  of  the 
time  uncertainty  involved  in  the  project.  Statements  about  the  probability  of 
meeting  schedules  and  other  worthwhile  information  for  management  can  be  de¬ 
rived  from  them.  Further,  their  use  keeps  an  activity  manager  from  being 
forced  to  state  and  work  with  a  rigid  tiipe  li^mit  which  he  knows  may  not  prove 
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to  be  very  realistic. 

Even  though  it  is  assumed  that  the  time  estimates  were  given  by  the 
people  most  qualified  to  make  them  --  people  at  the  lowest  level  who  have  full 
knowledge  of  the  activity  --  they  must  not  be  accepted  uncritically.  Manage¬ 
ment  wants  to  derive  the  best  possible  picture  of  the  entire  project,  and  it 
would  thus  not  be  wise  to  incorporate  times  which  responsible  individuals  in 
the  networking  groups,  or  in  management,  felt  were  unrealistic.  Some  ad¬ 
justments  can  be  made,  if  justified,  in  order  to  arrive  at  the  best  possible 
overall  picture.  Of  course,  both  sets  of  estimates  may  be  tested  when  there 
is  a  disagreement,  in  order  to  see  if  there  is  a  significant  difference  in 
the  completion  time  for  the  whole  project. 

V.  Conclusion 

The  above  coments,  suggestions  and  caveats  arise  from  the  author's 
experiences  during  a  number  of  network  development  sessions.  They  are  not 
designed  to  set  down  a  rigid  set  of  procedures,  adherence  to  which  will  ab¬ 
solutely  guarantee  a  successful  network.  Rather,  they  are  meant  to  be  help¬ 
ful  suggestions  to  be  applied  where  appropriate.  The  author  welcomes  addi¬ 
tional  comments  from  people  who  have  had  experience  in  networking  which  will 
either  support  those  in  this  paper,  add  to  them,  or  provide  reason  to  delete 


them. 


